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Tnis software is furnisned under a license for use only on a 


single computer system and may be copied only with the 
inelusion of the above copyrizght notice. This software, or 


any other eopies thereof, may not be provided or otherwiss 
made available to any otner person except for use on sucn 
system and to one wno agrees to these license terns. TLCiLe 
to and ownership ot the software shall at ali times remain 
in Digital Equipment Corporation. 


The information in this document is subject to chang 
without aotice and should not be construed as a commicment 
by Digital Equipment Corporation. 
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eee, Scope 

This document is a Specification of the cenemedia 
structure that is used by Files-i11. Piles-11 is a general 
purpose file structure which is intended to De the standard 


file structure for all mediuga to large PDP-11 systems. 
Small systems such as RT-11 have been specifically encluded 
Decause the complexity of Files-11 would impose too great a 
Ourdén on their Simplicity and small size. 


Thais document describes structure level 1 of Files-11, 
also referred to as ODS-1 (on-disk Structure version i). 
This is the only version of Files-11 which is implemented on 
any of the supporting Operating systems. A proposed 
Structure level 2 (ODS-2) exists but has not been 
implemented anywhere. | 


230 Medium 

Files-11 is a structure which is imposed on a anediun. 
faat medium must have certain Properties, which are 
descrivded in thea following section. Generally speaking, 


Dlock addressable Storage devices such as disks and Dectape 
are suitable for Files-i1,; hence Files-11 structured media 
are generically referred to as disks. : 


2.7 Volume 

The basic medium that carries a Files-11 Structure is 
referred to as avolume. A volume (also often referred to 
as a unit) is defined as an ordered set of logic2l blocks, 
A logical block is an array of 512 8-bit Dytes. The logical 
Dlocks in a volume are consecutively numbered from 0 to n-1, 
where the volume contains no logical blocks. The number 
assigned to a logical block is called its: logical Diock 
Rumber, or [LSN. Files-11 is theoretically capable of 
describing volumes up to 24*32 blocks in size. In practice, 
a volume should be at least 100 blocks in size to Se useful; 
current implementations of Files-11 will handle volumes up 
to 2*4*24 blocks. 


The logical blocks of a volume must. be randomly 
addressable. The volume must also allow transfers of any 
length up to 65k bytes, in multiples of four bytes. When. 2 
transfer is longer than 512 bytes, consecutively numbered 
logical blocks are transfered umceil the byte count is 
Satisfied. In other words, the volume can be viewed as a 
partitioned array of Oytes. It must allow reads and writes 
of arrays of any length less than 65k bytes, provided that 
they start on a logical block Soundary and that the length 
is a multiple of four Bytes. When only part of a block is 


written, the contents of the remainder of that logical block 
will be undefined. 


2.2 Yolume Sets 

volume set is a collection of related units that are 
nor mel Ly treateq as one logical device in the usual 
operating system concept. ae UNLC cOntaine 17S  cwn 
riites-11 structure; however, files on the various units in 


a volume set may oboe referenced with a relative yorum: 

umber, which uniquely determines which unit in the set tne 
file is located on. Other sections in this specification 
will make occasional reference to volume sets and relative 
volume numbers where hooks for their implementation exist. 
Since volume sets have not been implemented as yet, however, 
no complete specification is provided here. 


coas Files 


Any data in a volume or volume set that is of any 
interest (i.e., all blocks not available for allocation) is 
contained in a2 file. A file is an ordered set of virtual 
ploecks, where a virtual block is an array of 512 8 bit 
bytes. The virtual blocks of a file are consecutively 
mumbsred from 1 ton, where n blocks have been allocated to 
the file. The number assigned to a virtual block-is called 
(obviously} its virtual block number, or VEN. Fach virtual 
block is mapped to a unique logical block in the volume set 
by Files-11. Virtual blocks may be processed in the same 
manner as logical sloecks. Any array of bytes less than 65k-™ 
in length may be read or written, provided that the transfer 
starts on a virtual block ooundary and that its lengtn is #2 
multiple of four. 


a File 1D 


tad 


Each file in a volume set is uniquely identified ody a 
File ID. A&A File ID is a binary value consisting of 48 bits 
(3 PDOP-11 words). It is supplied by the file system -wnen 
the frie is created, and must be supplied oy the user 
woenever he wishes to reference a particular file. 


The tnree words of the File ID are used 2s follows: 

word 1 File Numser 
Locates the file within a particular unit of 
volume set. File numbers must lie in the ra 


through 65535. The set of file numbers on 2 es 
is moderately (but not totally) dense; at any 


instant in time 2 


Tile 
one file witnin thas Ui 
nord 2 Clle Sequence Number 
Identifies the current use of at  2ngividial fits 
nhumder on aiounit. File numbers are re-used; wnen 
a file is deleted its file mumder dSecomes 
available for future use for some other file, 


Each time a file number is rejw-used, a different 
file sequence number is assigned to distinguish 
‘the uses of that file number. The file sequence 
number is essential sinee it is perfectly legal 
for users to remember and attempt to use a File ID 
long after that file has been deleted. 


word 53 Relative Volume Number 


identifies which unit of a volume set the file is 
located on. Volume sets are at present not 
implemented; Che only legal value ror the 
relative volume number in any context is zero. 


52 File Header 

«© Each file on a Files-11 volume is described by a jie 
header. The file header is a block that contains all the 
information necessary to access the file. It is not part of 
Che file; rather, it is contained in the volume's index 
Pile. (The index file is described in section ree ee The 
header block is organized into four areas, of which the 
first three are variable in size. 


3.2.1 Header Area 


The information in the header area permits the 
file system to verify that this block is in fact a 
file header and, in Particular, is.the header 
being sought by the user. I¢ contains the file 
mumber and file sequence number of the file, as 
well as its ownership and protection codes. This 
area also contains offsets to the other areas of 
the file header, thus defining their size. 
Finally, the header area contains a user attribute 
area, which may be used by the user to store a 
limited amount of data describing the file, 


32242 Ident Area 


The ident area of a rie ee header contains 
identification and accounting data about the file. 
Stored here are the primary name of the file, its 


r 
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creation date and time, revision count, date, and 
Cine. and expiration cate. 


Gad 
NN 
dad 


ifdap Area 


Tne map area describes the mapping of virtual 
bloeks of the file to the logical blocks of the 
Q 


volume. The mapping data consists of a list of 
retrieval SOLTnusrs. nach retrieval pointer 
describes one logically contiguous segment or the 
Cite. The map area also contains tne Linkage to 
the next extension header of the file, if, ‘Such 
exists. 

3.2.4 End Checksum 


The last two bytes of the file header centain a 16 
bit additive checksum of the remaining 255 words 
of the file header. The checksum is used to help 
verify that the block is in fact a file hneader. 


3.3 Extension Headers 


Sine® the file header is of fixed size, it is 
inevitable that for some files the mapping information will 
not fit in the alloeated space. A File with a large amount 
of mapping data is therefore represented with a enain of 
file neaders. Each neader maps a consecutive set of virtual 


clocks; the extension linkage in the map area iinks the 
headers together in order of ascending virtual block 
numbers. 


Multiple headers are also needed for files that span 
units in a volume set. A header may only map logical blocks 
Located on its unit; - therefore a multi-volume file is 
represented by headers on all units that contain portions of 
that file. 


3.4 File Header - Detailed Description 
This section deseribdes in detail the items contained in 


the file header. Each item is identified by 2 symbol which 
represents the offset address of that item within its area 


in the file header. Any item may be located in the file 
header by locating the area to which it belongs and then 
adding the value of its offset address. Users who concern 


toemselves with tne contents of file headers are strongly 
urged to use tne offset symbols. The symbols may be defined 
in assembly language programs oy calling and invoking the 
macro FHDOF3, which may be found in the macro library of any 
system that supports Files-11. Alternatively, one may find 


r 
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Coe Dacro in ‘the file FIIMAC.MAC, which may de obtained fron 


tne author. 


3.4.1 header Area Description 
The header area of the file header always starts 
byte OQ. it contains the basic information needed 


cnecking the validity of accesses to thea Tile. 


Sire oe eee H.IDOF 1 Byte Ident Area Offset 


oe | a? 


ty 
© fi 


This byte contains the number of 16 bit words 
Detween the start of the file header and the start 


of the ident area. it defines the loeation of 
ident area and the size of the header area. 


3.4.1.2 H.MPOF 1 Byte Map Area Offset 


the 


This byte contains the number of 16 bit words 
Detween the start of the file neader and the start 


of the map area. It defines the location of 


map area and, together with H.IDOF, the size 


the ident area. 


Ste Tes H.FNUM 2 Bytes File Number 


ad 


This word contains the file mumber of the file. 


the 
oc 


3.4.1.4 H.FSEQ 2 Bytes File Sequence Number 
This word contains the file sequence number of tre 
fite. 

3.4.1.5 H.PFLEV 2 Bytes | File Structure Level 


The file structure level. is used to identify 
different versions of Files-11 as they affect the 
Structure of the file -header. This permits 


upwards compatibility of file structures 


as 


Piles-11 evolves, in that the structure level word 
identifies the version of Files-11 that created 
this particular file. This document describes 
version 1 of Files-11; the Only legal contents 


Tor d.FLEV is 401 octal. 


Bytes File Owner UIC 


3.4.1.6 H.FOWN 2 
H.PROG = H.FOWN+0 Programmer (Member) Number 
H.PROJ = H.FOWN+1 Project (Group) Nuaber 


This word contains the Dinary user identifiea 
code (UIC) of the owner of the File. The 
Owner is usually (but not necessarily) the cre 


C. 
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of the file. | ‘ 
oe i oat ©, 2 Bytes File Protection Code 
This word controls what access ali users in the 
system may nave to the file. Accessors of a file 
are categorized according to Ene Teleatvilonsais 
between tne UIC of the aceessor and tae VIC of the 
Owner of the file. Each category is contreiled by 
a four bit field in tne protection word. The 
category of the accessor is selected as follows: 
Systen Bits 0 = 3 

The aeceessor is subject tO system 


protection if the project number of the 
UIC under which he is running is 10 
octal or less. 


Owner Bits 4 - 7 


The accessor is subject to owner 
protection if the UIC under which he is 
running exactly matenes the file owner. 
ULC. 


Group Bits 8 - 11 


The accessor is subject to group 
protection if the project number of nis 
UIC matches the project number of the 
file owner UIC. 


world Bits 12 - 15 


The aecessor is subject ago) world 
protection if he does not fit into any 
of the above categories. 


Four types of access intents are defined in 
Files-11: read, write, extend, and delete. Each 


four bit field in the protection word is bit 


encoded to permit or deny any combination of the 
four types of access to that category of 
accessors. Setting a bit denies that type of 
aceess to that category. The bits are defined as 
follows (these values apply to a right-justified 
provecvion field): : 


FP.RDV Deny read access 
PRP IWRV Deny write access 
es age ee Deny extend access 


PP.DEL Deny delete access 
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4nen a@ user attempts to access a tide: pretection 


cnecks are performed in all tne categories to 
wnicn ne is eligible, in the order System = owner 
- groud - world. Tne user is granted aceass to 
the file if any of the catezories to which he is 
elizgibdle grants him access, 


H.rCHA 2 Bytes File Characteristics 
a@.UCHA = H.FCHA+0 User Controlled Cnar. 
H.SCHA = H.FCHA+1 System Controlled Char. 


The user controlled characteristics Dyte contains 
the following flag bits: 


UC.CON Set if the file is logically contisuous: 
i.e., if for all virtual blocks in the 
file, virtual block i maps to lLozieal 
block k+i on one unit for some constant 
K. This bit may be implicitly set or 
Cleared by file system operations that 
allocate space to the file; the user 
may only clear it explicitly. 


UC.DLK Set if the file is deaccess-locked. 
This bit is used as a flag warning that 
the file was not» properly closed and may 
contain inconsistent data. Access to 
the file is denied if this bit is set. 


The system controlled Ccnaracteristics byte 
contains the following flag bits: 


SC.MDL Set if the file is marked for delete. 
If this bit is set, further accesses to 
the file are denied, and the file will 
be physically deleted when no users are 
aceessing it. 


sC.BAD Set if there is a bad data block in the 
file. This bit is as yet unimplemented, 
It is intended for dynamic bad block 
handling. 


H.UFAT 32 Bytes User Attribute Area 


This area is intended for the Storage of a limited 
quantity of "user file eUuriloutes". deé@e,; any date 
the user deems useful for processing thea file that 
ls not part of the file itself. An example of the 
use of the user attribute area is presented in 
Section 6.1 (FCS File Format). 


3.4.1.10 S.HDHD 46 Bytes Size of Header Area 


This symbol represents the total size of the 
header area containing all of the adove entries. 


3.4.2 Ident Area Description 


The ident area of the file header begins at the word 
indicated bY ft. DOF. It contains identification and 
accounting data about the file. 


3.4.2.1 I. FNAM 6 Bytes File Name 


Tnese three words contain the name of the file, 
packed three Radix-50 characters to the word. 
This name usually, but not necessarily, 
corresponds to the name of the file's primary 
directory: entry. 


5042222 a gs es 22 2 Bytes File Type 


This word contains the type of the file in tne 
form of three Radix-50 characters. 


3.4.2.3 I.FVER 2 Bytes Version Number 


This word contains the version number of the file 
in binary forn. a 


3.4.2.4 I.RVNO 2 Bytes Revision Number 

This word contains tne revision count of the file. 
Tne revision count is the number of times the file 
has been accessed for write. 


3.4.2.5 I.RVDT 7 Bytes Revision Date 


The revision date is the date on wnicn the file 
was last deaccessed after being accessed for 


write. It is stored in ASCII in the form 
"DDMMMYY", where DD is two digits representing the 
day of the month, MMM is three characters 


representing the month, and YY is the last two 
digits of the year. , 


A 
- 
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ae re a Gal o Bytes Revision Time 


The revision time is the time of day on which the 
File was last deaccessed after being aceessed for 
write. LG 2s. stored 2o- ASCiIZ -in thre -formac 
"HEEMMSS™, . WRETe Hd Ls. the nour, MM 29 the minuve, 
ana SsS- is tne second. 
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I.CRDT 7 Bytes Creation Date 


These seven bytes contain the date on whien ¢ 
file was created. Tne format is the same as th 
of the revision date above. 


he 
at 
3.4.2.8 LeChi. 6 Bytes Creation Time 
These six bytes contain the time of d2y ate which 
the file was created. The format is the same as 


that of the revision time above. 


I. EXDT 7 Bytes Expiration Date 


a) 
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These seven bytes contain the date on which the 
file becomes eligible to be deleted. The format 
is the same as that of the revision and creation 
dates above. 


da) 


4.2.10 - 1 Byte (unused) 


This unused dyte is present to round up the size 
if the ident area to 2 word boundary. 


3.4.2.11 S.IDHD 46 Bytes Size of Ident Area 


This symbol represents the size of the ident “area 
containing all of the above entries. 


a) 
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Map Area Description 


The map area of the file header starts at the word 
indicated by H.MPOF. It contains the information necessary 
to map the virtual blocks of the file to the logical blocks 
of the volume. 


Setesa M.ESQN 1 Byte Extension Segment Number 


This byte contains the value nm, where this header 
is the n+1tth header of the file; L.e., headers of 
a file are numbered sequentially starting with 0. 


3.4.3.2 M.ERVN 1 Byte Extension Relative Volume No. 


This byte contains the relative volume number of 
the unit in the volume set that contains the next 
Sequential extension header for this file. ey 
there is no extension header, or if the extension 
header is located on the same unit as this header, 
this byte contains Q. 


Ua) 
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M.EFNU 2 sytes Extension File Number 

This word contains the file numder of the next 
Sequential extension header for this file. Le 
there is no extension neader, this word contains 
QO. 

Nese so 2 Bytes Bxtension File Sequence Number 
This word contains the file sequence numder of the 
next sequential extension header for tnis file. 
If there is .no extension header, this word 


‘e@ontains Q. 


M.CTSZ 1 Byte Block Count Field Size 


This byte contains a count of the numder of bytes 
used to represent the count field in tne retrieval 
pointers in the map area. Tne retrieval pointer 
format is described in section 3.4.3.9 below. 


M.LBSZ 1 Byte LBN Field Size 


Tais byte contains @ count of the number of bytes 
used to répresent tne Logical block number field 
in the retrieval pointers in the-map area. The 
contents of M.CTSZ and M.LBSZ must add up to an 
even number. - 

a 


M.USE 1 Byte Map Words In Use 


This byte contains a count of the number of words 
in the map area that are presently occupied oy 
retrieval pointers. 


M.MAX 1 Byte Map Words Available 
This byte econtains the total number of words 
ap area. 


available for retrieval pointers in the mn 
M.RTRV Variable Retrieval Pointers 


This area contains the retrieval pointers that 
actually map the virtual blocks of tne file to the 
logical blocks of the volume. Bach retrieval 
pointer describes a consecutively numbered group 
of logical blocks which is part of the file. The 
eount field contains tne binary value nan to 
represent a2 group of neil logical blocks. The 
logical block number field contains the logical 
block numoder of he first Logical dlock “in sh 
group. Thus each retrieval pointer maps virtua 
Olocks j through j+n into logical blocks & throug 
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K+n, respectively, where 3 is the tetal nunder 
plus one of virtual blocks represented by a 
preceding retrieval pointers in this and 3 
preceding headers of the file, nm is the val 
contained in the count field, and k is the value 
contained in the logical block number field. 


Although the data in the map area provides for 
ardDitrarily extensibdle retrieval pointer formats, 
Flles-11 nas defined only three. Of these, only 
the first is currently implemented; the other two 
are =presented- out of historical interest and 
Decausée they may be resurrected in the future. 


; 


Format 1: M.CTSZ 
: 3 


M.LBSZ 


The total retrieval peointer length is 
Tour bytes. Byte 1 contains the hizh 
order bits of the 24 bit LBN. Byte 2 
contains the count field, and bytes 3 
and 4 contain the low 16 bits of the 
LEN. | 


' j . | 
i Count | High 

j wm mwmmemonn ns! a - 
' 

$ 

| 

{ 


Low Order LBN 


Format 2: M.CTSZ =z 
M.LES2Z -s: 2 


The total retrieval pointer length i 
four bytes. The first word contain 
16 bit count field and the second w 
contains a 16 bit LBN field. 


O W 
"3 


t 
’ j 
Count 
1 } 
Le tn ee ae oe oe ere eee eee ee 
LBN 
| wen e--+---~ +--+ ------ | 
Format 3: M.CTSZ = 2 
M.LBSZ = 4 


The total retrieval pointer lengtn i 
Six bytes. The first word eentains a 1 
bit count field and the second and thir 
words contain a 32 bit LBN field. 


2 


a 


Count 
| mae ween ee ~ +--+ ee : 
High 
[= LBN ae, 
Low 
J } 
Se ee ee ee a ee ee 
3.4.3.10 S.MPHD 10 Bytes Size of Map Ares 
This symbol represents the size of the map area, 
not including the space used for the retrieval 
“pointers... 
3.4.4. End Checksum Description 


The neader check sum occupies the last two bytes of the 
file header. It ais verified every time a header is read, 
and is recomputed every time a header is written. 


3.4.4.1 H.CXSM 2 Bytes Block Checksum 
This word is a simple additive checksum of all 


other words in the block. It is computed by the 
following PDP-11 routine or its equivalent: 


MOV Header-address,k0 
CLR R 
MOV P25 Saye 
103: ADD (RO)+,R1 
SOB R2,105 


MOV R1,(R0) 
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File Header Layout 
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H.PROJ 


H.SCHA 


Ident Area 
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File Protection 


User Attribute Area 


File 
File 
Version 
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Number 
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H.FSEQ 


H.FLEV 


. H.FOWN 


H.PROG 
aah PRO 
H.FCHA 
A.UCKA 


H.UFAT 


S.HDAD 


de 


Loe ae 
Loh R 
I.RVNO 


Lan DT 


Le CROT 


Map Area 


M.ERVN 


M.OBSZ 


-M.MAX 


man ee eRe ete ewar anew 


wen ee awe ae et ae Ct Oe 
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man ame Ree One awe SF STP awe ae oe 
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-= Revision Time -= 
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S.IDHD 


MUSE 
S.MPHD 
M.RTRV 
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4.0 Directories 

Flles-i1 provides directories to allow the organization 
of Tiles ini a@&. Weanhineful wayu While tne File IDiis 
sufficient to locate a file uniquely on a volume Secu, it is 
nmardly mnemonic. Directories are files whose sole function 
1S to associate file name strings with File ID's. 
4.1 Directory Heirarchies 


Since directories are files with no special attributes, 
directories may list files that are in turn directories. 
Thus the user may construct directory heirarchies of 
arbitrary depth and complexity to structure his files as he 
pleases. 


Bold. User File Directories 


. Current implementations of Files-11 all support 2 two 
level directory heirarchy which is tied in with the user 
identification mechanism of the operating system. Each UIC 
is associated with a user file directory (UFD). References 
to files that do not specify a directory are generally 
defaulted to the UFD associated with the user's UIC. All 
UFD's are listed in the volume's MFD under a fille name 
constructed from the UIC. A UIC of ({n,m] associates with a 
directory name of "nnnmmm.DIR;1", where nnn and mmm are on 
and m padded out to three digits each with leading zeroes. 
Note that all number conversions are done in octal. 


Two points should be noted here. The UFD structure 
described here is not intrinsically part of the Files-11 
onedisk structure; rather, it is a convenient cataloging 
System applied by various operating systems. Also, there is 
no hard and fast relationship between the owner UIC of a 
file and the UFD in which it is listed. Generally, they 
will correspond, but not necessarily. 


4.2 Directory Structure 


A directory is a file consisting of 16 byte records. 
It 1s structured as an FCS fixed length record file, with no 
carriage control attributes (see section 6 for a description 
of FCS files). Each record is a directory entry. The 
entries are not required to be ordered, or densely packed, 
mor dco they have any other relationship to each other, 
except that no two entries in one directory may contain the 
same name, type, and version. Each entry contains the 
followinz: 


a 
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File 1D The three word binary File ID of the file that 
tnis directory entry represents. if ‘Gre Tite 
mnumoer portion of tne File ID field is zero, onen 
this record is empty and may de used for a new 
directory entry. 

iane Tae name of tne file may be up to 9 characters. 
It is stored as three words, each containing three 
Radix-50 packed characters. 

Type The type of the file (also historically referred 
to as the - extension) may be up to three 


Characters. It is stored as one word of Radix-50 
packed characters. 


Version The version number of the file is stored in binary 
in one word. 


j 

j 
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j t 
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File ID 
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Name 
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Type 

| pane eee ---- oe -e| 

i Version 

| panne ee == +--+! 
4.3 Directory Protection 

Since directories are files with no special 

characteristics, they may be accessed like all other files, 
and are subject to the same protection mechanisn. | However, 
implementations of Files-11 support three special functions 
for the management of directories, namely FIND, REMOVE, and 
ENTER. A user performing such a directory operation must 


have the following privileges to be allowed the varicus 
functions: | 


FIND: READ 
REMOVE: READ, WRITE 
ENTER: READ, WRITE, EXTEND 


es] 
4 
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5:0 known Files 


Clearly any file system must maintain sone dq 
Structure on the medium which is used to egontrol the f 
organization. In Files-11 this data is kept in five fil 

Tnese files are: created when 2 new volume is initialized. 


Tnese five files have the following uses: 


File ID 1,1,0 is tne index file. The index file is the 
root of the entire Files-11 #£4structure. It contains the 
volume's bootstrap block-and the home block, which is used 
to identify the volume and locate the rest of the file 
structure. The index file also contains all of the file 
headers for the volume, and a bitmap to control the 
allocation of file neaders. 


File ID 2,2,0 is the storage bitmao file, It is used 
to control the allocation of logical blocks on tne volume. 


File ID 3,3,9 is the bad block file. It is a file 
containing all of the known bad blocks on the volume. 


_ File ID 4,4,0 is the volume master file directory (or 
MeO). It forms the root of the volume's directory 
Structure. Tne MFD lists the five known files, all first 
level .-user directories, and whatever other files the user 
chooses to enter. 7 a 


File ID 5,5,0 is the system core imazse file. Its use 
is operating system dependent; its basic purpose is to 
provide a file of known File ID for the use of the operating 
systen. 


oe ee index File 


The index file is File ID 1,1,0. It is listed in the 
MFD as INDEXF.SYS3;1. Tne index file is the root of the 
Files-11 structure in that it provides the means (for 
identification and initial access to a Files-11 volume, and 
contains the access data for all files on the volume 
(ineluding itself). 


=e ee Bootstrap Block 

Virtual block 1 of the index file is the volume's boot 
D Oe es. It is always mapped to logical block 0 of the 
volume. if the volume is the system device of an operating 
systen, the dDoot block contains an operating systen 


dependent program wnich reads the operating system into 
memory when the boot bleck is read and executed by a 
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Nhardware bootstrap. If the volume is not a systen 


machine's 
device, the soot block contains a small progrem that Cutputs 
a message on the system console to inform the operator to 
that effect. 
Se Vee fiome Block 

Virtual block 2 of the index file is the volume's home 
bleck. The logical block containing the home block is the 
first good block on the volume out of the sequence 1, 255; 


512, 763, 1024, 1280, .... 2565#n. The purpose of the hone 
block is to identify the volume as Files-11, establish the 
Specific identity of the volume, and serve as the ground 
zero entry point into the volume's file structure. The home 
plock is recognized as a home block By the presence of 
cnecksums in known places and by the presence of predictable 
values in certain locations. 


Items contained in the home block are identified DY 
Symodolic offsets in the same manner as items in the file 
header. The symbols may be defined in assembdly language 
programs By calling and invoking the macro HMBOFS, which may 
be found in the macro library of any system that Supports 
Files-11. Alternatively, one may find the macro in the file 
FIIMAC.MAC, which is available from the author. 


5.1.2.1 H.IBSZ 2 Bytes Index File Bitmap Size 


This 160 bit word contains the number of blocks 
that make up the index file bitmap. (The index 
file bitmap is discussed in section §.1.3.) This 
value must be non-zero for a valid Home block. 


ets ewe H.IBLB 4 Bytes Index File Bitmap LBN 


This double word. contains the starting logical 
Block address of the index file Bitmap. Onee tha 
home block of a volume has been found, it is this 
value that provides access to the rest of the 
index file and to the volume. The LBN is stored 
With the high order in the first 16 bits, followed 
by the low order portion. This value must be 
non-zero for a valid home block. 


De tae ss H.FMAX 2 Bytes Maximum Number of Files 


This word contains the maximum numb 
that may be present on the volume at any 
This value must be nonezero for 4 

Seek. | 
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' H.SBCL 2 Bytes Storage Bitmap Cluster Factor 


52 Vega 

This word contains the eluster factor used in the 
storage bitmap file. ine CLluscer factor is tne 

number of olocks reoresented by each bit in the 
Storage Ditmap. Volume SLUSterine is nogk 
implemented at peewee the only legal value for 
this item is 1. 

5.1.2.5 G.DVTY 2 Bytes Disk Device Type 
This word is an index identifying the type of disk 
that contains this volume. It is currently not 
used and always contains 0. 

5.1.2.8 R.VLEV 2 Bytes Volume Structure Level 
This word identifies the volume's structure Level. 
Like the file structure level, this word 
identifies the version of Files-11. which created 
tnais volume and permits upwards compatibility of 
media as Files-11 evolves. The volume structure 
level is affected by all portions of the Files-11 
structure except the contents of the file header. 
This document describes Files-11 version 1; the 
only legal value for one structure level is 401 
octal. 

oe eee | H.VNAM ' 32 Bytes Volume Name 

This area contains the volume iabel as an ASCII 

String. It is padded out to 12 bytes with nulls. 
The volume label is used to identify individual 
Files-11 volumes. 

Se ee ko - 4 Bytes Not Used 

Slee H.VOWN 2 Bytes Volume Owner UIC 
This word contains the binary UIC of the owner of 
the volume. The format is the same as that of the 
file owner UIC stored in the file header. 


5.1.2.10 H.VPRO 2 Bytes Volume Protection Code 


This word contains the protection code for the 
entire volume. Its contents are coded in the sams 
Manner as the file protection code stored in the 
file neader, and it is interpreted -in tne same way 
in conjunction with the volume owner JUIC. All 
Operations on all files on the volume must p2ss 
Doth the volume and the file protection check to 
oe permitted. (Refer to the discussion on file 


Sa tee eto 
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wd 


hN 


protection in section 3.4.1.7). 


HVCEA 2 Bytes Volume Characteristics 
This word contains bits which provide additional 
control over access to tne volume. ine: following 


Oilts 2re defined: 


e@ control functions 2re noc 
on Sais volume. Devices 
control functions are those which .2.4n 
threaten the integrity of the volume, 
Such as direct reading and writing of. 
Logical blocks, ete. | | 


CH.NDC S Vie 
D 


CH.NAT Set if the volume may not be attached, 
1.e., reserved for the sole use by one 
task. 

A. FPRO 2 Bytes Default File Protection 


This word contains the file Protection that will 
be assigned to all files created on this volume if 
no file protection is specified Dy the user. 


=~ 6 Bytes Not Used 
Be WlSZ 1 Byte Default Window Size | 
This byte contains the number of retrieval 


pointers that will be used for the "window" (in 
core file access data) when files are acaessed on 
the volume, if not otherwise specified oy the 
accessor. 


H.FIEX 1 Byte - Default File Extend 


This byte contains the number of blocks that will 
be allocated to a file when a user extends the 
file and asks for the system default value for 
allocation. 


H.LRUC 1 Byte Directory Pre-access Limit 


This byte contains a count of. the number of 
directories to be stored in the file system's 
directory access cache. More Zenerally, it is 2 
estimate of the number of concurrent users of th 
volume and its use may be Zeneralizec in = 
future. : 
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“ 11 Bytes Not Used 
f.CHK1 2 Bytes First CnecksuZ 


This word is an additive checksum of all entries 
preceding in the home block (i.e., all those 
listed above). It is computed ody the same sort of 
alsorithm as the file header checksum (see section 
3.4.4.1). 


H.VDAT 14 Bytes Volume Creation Date 


This area contains the date and time that the 
volume was initialized. it is in the format 
*DDMMMYYHHEMMSS", followed followed by a single 
null. (The same format is used in the ident area 
of the file header, section 3.4.2). 


2 393 Bytes Not Used 


This area is reserved for the relative volume 
table for volume sets. 3 


H.INDN 12 Bytes Volume Name 


Tois area contains another copy of the ‘ASCII 
volume label. It is padded out to 12 bytes with 
Spaces. It is placed here in accordance with the 
proposed volume identification standard. 


di. INDO 12 Bytes Volume Qwner 


This area contains an ASCII expansion of the 
volume owner UIC in the form "[proj,progj". Both. 
numbers are expressed in decimal and are padded to 
three digits with leading zeroes. Tne area is 
padded out to 12 bytes with trailing spaces. It 
is placed here in accordance with the proposed 


volume identification standard. 


H.INDF 12 Bytes Format Type 


This field contains the ASCII string "DECFILEI1A" 
padded out to 12 bytes with spaces. It identifies 
the volume as being of Files-11 format. It is 
placed here in accordance with the proposed volume 
identification standard. 


—_ 


- 2 Bytes Not Used 


an 
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ein Oe 2 Se 2 Bytes Second Checksum 

This word is the last. word of the home bdDicek. pis 
contains an additive enecksum of the preceding 255 
words of tne nome dDlock, computed according to the 


algoritnm listed in section 3.4.4.1. 
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fome Block Layout 
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Index File Bitmap Size 

I en ee ee ee =m @ 28 ep ee oe @ a oD 
Index File 

H 
7  eeagtinad ap aD 
Bitmap LBN 

i 
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Maximum Number of Files 

5 
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Volume Structure Level 
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Volume Nane 
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Volume Owner UIC 

| 
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Volume Protection 
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Volume Characteristics 
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Default File Protection 
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H.FMAX 


H.SBCL 
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H.VLEV 


H.VNAM 
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H.VPRO 
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ma ae _ Index File Bitmap 


The index file bitmap is used to control the allocation 
of file numbers (and hence file headers). It is simply a 
bit string of length n, where n is the maximum number of 
files permitted on the volume (contained in offset H.FMAX in 
the home block). The bitmap spans over as many blocks as is 
necessary to hold it, i.¢e., max number of files divided by 
4090 and rounded up. The number of blocks in the bitmap is 
contained in offset H.IBSZ of the home block. . 


The bits in the index file bitmap are numbered 
sequentially from 0 to n=-1 in the obvious manner, i.e., from 
right to left in each byte, and in order of increasing byte 


address. Bit gj is used to represent file number j+1i: if 
the bit is 1, then that file number is in use; if the bit 
is Q, then that file number is not in use and may be 


assigned to a newly created”” file. 


The index file bitmap starts at virtual block 3 of the 
index file and continues through VBN e2+m, where m is the 
number of blocks in the bitmap. It is located at the 
logical block indicated by offset H.IBLB in the home bleck. 


5.1.4 File Headers 


The rest of tne index file e¢ontains all tne file 
neaders for the volume. The first 16 file headers (for file 


PILES<11 ON-DISX STRUCTURE PAGS: 27 


numbers 1 to 16) are logically contiguous. witn the index 
file bitmap to facilitate their location; the rest may be 
allocated wnerever tne file system sees fit. Thus the first 
16 file headers may be located from data in the home block 
(H.1LBSZ and H.IBLS) while the rest must be located through 
the mapping data in the index file haader. The file header 
for file number n is located at virtual block 2+m+n (where om 
is the number of blocks in the. index file bitmap). 


Se Storage Bitmap File 


The storage bitmap file is File ID 2,2,0. It is listed 
in the MFD as BITMAP.SYS;1. The storage bitmap is used to 
control the available space on a unit. It eonsists of a 
storaze control oalock which contains summary information 
about the unit, and the bitmap itself which lists the 
availablilty of individual blocks. 


Siew I Storage Control Block 


Virtual block 1 of the storage bitmap is the storage 
control block. It econtains summary information intended to 
optimize allocation of space on the unit. The foll:wing 
‘items are in the storage control. block: 
bytes) Not used (zero) 
byte) Number of storage bitmap blocks 
Ovtes) Number of Fre blocks in ist bitmap block 
Dytes) Free block pointer in ist bitmap block 


CON LN LON OTN 
MM fO — 


(2 bytes). Number of free blocks in nth bitmap block 
(2 bytes) Free block pointer in nth bitmap block 
(4 bytes) Size of the unit in logical blocks 


Note: Current implementations of Files-11 do not correctly 
initialize the word pairs containing number of free blocks 
and free block pointer for each bitmap block, nor are these 
values maintained as space is allocated and freed on the 
unit. They are therefore best looked upon as 2n garbdazge 
words and snould not be used by future implementations of 
Files-11 until the disk structure is formally updated. 


Bee ae Storage Bitmap 

Virtual blocks 2 through n+1 are the storege bitmap 
itself. It is oest viewed as a bit string of length a, 
mumbered from 0 to m-1, where m is the total numbder of 
logical bleeks on the unit rounded up to the next multiple 
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of 4090. The bits are addressed in the usual manner (packed 
right to left in sequentially numbered bytes). Sinze each 
virtual block holds 4096 bits, n dlocks, where n = m/4O0956, 
are used to nold the bitmap. Bit j of the bitmap reoresents 
logical block j of the volumes; if tne bit is set, the block 
is free; if clear, ‘the Block is allocated. Clearly tne 
Last kK Dits of the bitmap aré always clear, where k is the 
difference between the true size of the volume and a, the 
Lenstn of tne: Dicaao. 


5.3 Bad Block File- 


The bad plock file is File ID 3,3,;0. It. is listed in 
the MFD as BADBLK.SYS3;1. The bad block file is simply a 
file containing all of the known bad blocks on the volume. — 


S456 Bad Block Descriptor 


Virtual block 1 of the bad block file is the bad bdlock 
descriptor for the volume. It is always located on the last 
good block of the volume. This block may contain a listing 
of the bad blocks on the volume produced by a bad block scan 
program or diagnostic. The. format of the bad block data is 


identical to the map area of a file header, except that the 


first four entries (M.ESQN, M.ERVN, M.EFNU, and M.EFSQ) are 
not present. - The last word of the-block contains the usual . 
additive checksum. (See section 3.4.3 for @ description of 
the map area.) This block is included in the bad block file 
tO save the data it contains for future re-initialization of 
the volume. | 


Bad Block Descriptor Layout 
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5.4 Master File Directory : 

Toe master file directory is File ID 4,4,90. ro. ass 
listed in the MFD (itself) as 990000.DIR;1. The MFD is the 
root of tne volumes directory -structure. Lt dists tne five 
<nown files, plus whatever the user cnooses to enter in 
tne two level UFD structure described in section 4.1.1, the 


! 
MeO contains entries for ail user file directories. 


5 Core Image File 


iGe Core image file ts File 1D 545,00. 20.28 sisted in 
the MFD as CORIMG.SYS;1. Its use is operating systen 
dependent. In general, it provides a file of known File ID 
for the use of the operating system, for use as 2 sw2p area, 
for example, or as a monitor overlay area, etc. 


6.0 FCS File Structure 


File Control Services (FCS) is a user level interface 
to Files-11. Its principal feature is‘a record control 
facility that allows sequential processing of variable 
length records and sequential and random access to fixed 
lengtn record files. FCS interfaces to the virtual block 
facility provided by tne basic Files-11 structure. 


6.1 FCS File Attributes 


FCS stores attribute information about the file in the 
file's user attribute area (H.UFAT - see section 3.4.1.9). 
it uses only the first 7 words; the rest are ignored by 
FCS, but are reserved by DEC (see Section 7.1 RMS FILE 
ATTRIBUTES). The following items are contained in the 
attribute area; they are identified oby the usual symbolic 
offsets (relative to the start of the attribute area). Tne 
offsets may be defined in assembly language programs by 
calling and invoking the macro FDOFF$ DEFSL. Flag values 
and bits may be defined by calling and invoking the macro 
FCSBTS. These macros are in the system macro library of any 
Operating system that supports Files-11. Alternatively, all 
these values are defined in the system object library of any 
System that supports Files-11, and may be obtained at link 
time. | 


a1 64 F.RTYP 1 Byte Reeord Type 
This byte identifies which type of records are 


contained in this file. The following three 
values are legal: 
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Ree Ls Fixed length records. 

R.VAR Variable length records. 

R.SEQ Sequenced Variable Length records 
Oo.1.2 F.LRATT 1 Byta Record Attributes 


This Byte contains preecord attribute bits that 
eontrol the nandling of records. under various 


contexts. The following flag bits are defined: 

FD.&FTN Use Fortran carriage control if set. 
The -first byte of each record is to 52 
interpreted as a standard Fortran 
carriage control character wnen the 
record is copied to a carriage control 
device. 

FD.CR Use implied carriage control if set. 


When the file is copied to a carriages 
eontrol device, each record is to de 
preceded by a line feed and followed by 
aecarriage return. Note that the FD.FTN 
and FD.CR bits are mutually exclusive. 


FD.PRN Used to indicate. that _the two byte 
sequence number fieid for R.SEQ record 
format is to be interpreted as print 
control information (see Section 6.2.3.1 

for format of print information). 


PD;BLX Records do nat cross block boundaries if 
set. Generally, there will be deac 
Space at the end of each block; how 


this is hnmandled is explained in the 
description of record formats in section 


6.2. 

6.1.3 F.RSIZ 2 Bytes Record Size 
In a fixed length record file, this word contains 
the size of the records in bytes. In a variable 
or sequenced variable length record file, this 
word contains the size in bytes of the longest 
record in the file. | : 

6.7.4 F.HIBK 4 Bytes Highest VEN Allocated 


This 32 bit number is a count of the number of 
virtual blocks allocated to the file. Since this 
value is maintained by FCS, it is usually correct, 
but it is not guaranteed sinee FCS is a user level 
package. 
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O15 eae Oe = 4 4 Bytes End of File Block 


This 32 bit number is the V8N in which 


tn 
file is located. Both F.L.HIBK and ae 
ej 


stored with the high order nalf in the 
bytes, followed dy the low order half 


Os tao PPE SL 2 Bytes First Free Byte 


end of 
SFSBK are 
rst two 


Tnis word is 2 count of the numder or bytes in use 
in the virtual block containing the end of file; 


i.e., it is the offset to the first byte 


of the 


file available for appending. Note that an end of 


file that falls on 2 block boundary 


may be 


represented in either of two ways. If the file 
contains precisely n blocks, F.EFBK may contain na 
and F.FFBY will contain 512, or F.EFBK may contain 


— 


n+? and F.FFBY will contain Q. 


Oe te S.FATT 14 Bytes Size of Attribute Block 


This symbol represents the total numbder 
in.the FCS lle attrisute obilock. 


O.7.A FCS File Attributes Layout 


t 
i} 

F.RATT Record Attr. Record Type 
i 


“Highest VBN 


Allocated 
1 
t 


6.2 Record Structure 


This section describes how records aré Stet 
virtual biocks of a disk file. in pipiens eos 


disk file as a sequentially numbered rray 


Records are numbered consecutively starting “with I a 


of bytes 


PgRILE 
F.RSIZ 


F.HIEX 


F.EFBEK 


Piece tos 
S.FATT 


ee 
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Fixed Lenstn Records 


in @ file @qonsistinge <of fixed. ieneta records, the 
records are simply packed end to and with no additional 
control information. If the . record length is odd, each 
record is padded witn a single dByte. The content of tne pad 
oyte is undefined. For direct access, the address of 2 
record is computed as follows: 


Let: n= record number 
K = record size (in bytes) 
m= byte address of record in tite 
q = mumber of records per block 
j = VBN containing the start of the pesoes 
i = byte offset within VEN j 
then ((k*1)/2)*2 (rounded up record length) 


(ne1)*h 
m/512+1 (truncated) 
m mod 512 


Ko 8 > 


Tne previous discussion assumes that records cross block 
boundaries (that is, FD.BLK is not set). If records do not 
cross block boundaries, they are limited to 512 bytes, and 
the following equations apply (the variables are defined as 


above): | ; 
h = ((k+1)/2)#2 (rounded up record length) 
q = 512/k (truncated) 
j = (m-1)/q+1 (truncated) 
i = ((n-1) mod q)*h 
eRe eer Variable Length Records 


In a file consisting of variable length records, 
records may be up to 32767 bytes in length. Each record is 
preceded by & two byte binary count of the bytes in the 
record (the count does not include itself). For example, a 
null record is represented by a single zero word. The byte 
eount is always word aligned; i.e., if a record ends on an 
odd pyte boundary, it is padded with a single byte. The 


content of the pad byte is undefined. 


If records do not cross block boundaries (FD.BLK is set), 
they are limited to a size of 510 bytes. A byte count of -1 
is used as a flag to signal that there are no more records 
in a particular block. The remainder of that block is then 
dead space and the next record in the file starts at tne 
beginning of the next block. 


+ ee meee on ere 


6.2.3 Sequenced Variable Length Records . 


Tne format or a sequenced file is identical to 2 
variable length record file except tnat a two byte sequence 
nmumoer field is located immediately after the byte count 
fleld of each record. This field contains a binary values 
wnoien is usually interpreted as tne line number of that 
record (see Section 6.1.2 FD.PRN and Section 6.2.3.1). The 
sequence number is not returned as part of tne data when 3 
-pecord is read, but is available separately. Note that the 
record byte count field. counts the sequence number field as 


well as the data of the record. 


6.2.5.1 Format of Two Byte Print Control Field in R.SEQ 
Records | ~ 


Lf tne FD.PRN bit is set in the record attribute sagt 


en 
the two byte "sequence number" field is used to contain 
Carriage control data for the reeord. Byte. © 28: ‘oOFrinc 


control information to act upon before the record data is 
Output to a unit record device; byte 1 Ls ‘print -control 
information to act upon after the record data has been 
Output to a unit record device. . 


The format of each byte is as follows:. 


Bit 7 Bits 6-0 Meaning 
0 Q No carriage control 
0 count(1-=127) "count" new lines (CR/LF) 
Bit 7 Bit 6 Bit 5 Bits 4-0 Meaning 
1 Q Q ASCII co SET ASCII CHAR TO 
OUTPUT (CR,FF etc.) 
1 0 1 ASCII Ci SET ASCII CHAR (8 BIT CODE) 
TO QUTPUT 
1 1 8) CODE (0-63) Device specific code 
1 1 1 = Reserved 
NOTE 


The print control field is not currently supported 
bY FCS Or RMS=117, 


ee ee we ere rt 
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RECORD MANAGEMENT SERVICES (RMS) 


Record Management Services (RMS) is 2 user level 
interrace to Files-11. It provides a flexible means of data 
storage, retrieval, and nodification throuzh 2 comdination 
of file Organization and record access nodes. File 
Organization is the structure of data within the virtual 
Olocks of a fFiles-1i file, and record access mode is the 
manner in which storing and retrieving tne data in tha file 


occurs. 
RMS supports/defines three file organizations which are: 


- Sequential = compatible with FCS fixed, variable, 
and sequenced variable record files (see Section 6) 


-. Relative - RMS only 
. indexed = RMS only 


RMS interfaces to the virtual block facility provided by the 
Filés-11 structure. 


a 


TOs * Data Formats and Representation 


RMS supports file organizations which require a more 
complex degree of structuring than that required by FCS. 
RMS also stores binary values in a different manner in. 
general tnan Files-11 defines. For these reasons the data 
format and representations used by RMS are given in the 
Following sections. 


sre 8 ares are String Storage 


All strings are stored left justified. The left most 
Cnaracter is in byte N and the right most character is in 
byte N+eM-1 where M is the length of the string. 


CSeste 2 String Character Code Set 


All string values are assumed to be in the 7=-bit ASCII 
code set. 
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1sOutes String Collating Sequence ° 


Tné collating sequence used is thn 
S 

woere NUL iS tne lowest Valued oh 
nighest valued character. 


NOTE 
The internal representation of ASCII characters on 


PDP-11 systems is-.7-bit ASCII. The string compare 
routine of RMS-11 however, performs a full 8-bit 


unsigned compare per character. RMS does not 
perform any "clear bit 7" code on input or output 
Operations. This allows the support of user binary 


byte strings, the KANA character set used in Japan, 
and’ in the future 8-bit ASCII when defined, without 
AMS modifications since the true colating sequence 
is lowest character = 0 and highest character = 255. 


7.0.7.4 Unsigned Binary Value Storage 


All unsigned binary Values are stéred with the Least 
Significant Rits (LSB) in’byte N and the Most Significant 
Bits (MSB) in byte N+M-1 where M is the length of the binary 
Value. 


EXAMPLE: 2 byte unsigned binary value 


t+ MSB j Ne! 


7.0.1.5 Signed Binary Value Storage 


All signed binary values are stored as unsigned binary 
values except that most significant bit (bit 7 of byte 
N+M-1) of the value is interpreted as the sign of the ° 
Nezgative mumbers are stored as the two's complems 
positive value. 
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EXAMPLE: 2 bdyte signed binary value 


~ 

oO 
- 
Oo 


Pointer Values 


All pointers are stored as unsigned binary. values. 
Pointers are stored variable length. The length of a 
pointer value is specified by the control bits associated 
with the pointer. The length requirement for a pointer is 
aetermined dy the range of VEN values it falls in as 
follows: | 3 


2 bytes start V8N 1 = 65,535 
3 bytes start VBN 65,536 - 16,777,215 


4 bytes start VBN 16,7 


| 
—~] 
hw 
pus 
Ov 
| 
+= 
N 
Va) 
4= 
oO 
Ov 
—~ 
Ae) 
Oo 
wi 


y cae © rae (are Bucket Pointers _ 7 


A Bucket pointer is a pointer value which specifies the 
start VEN of the bucket. The length of the bucket (number 
of VBN's in bucket) is interpreted in the context of its 
usage within the file, and is specified in the file's prolog 
data. 


EXAMPLE: 2 byte bucket pointer 


7.0.1.8 Record Pointers 

Record pointers are composed of two rields, 2 one odyite 
record ID field followed by a bucket pointer. The ID is 
used as a unique record identifier for records within a 
dDucket. The records are tagged with their ID'S when stored 
in the bucket. 


Pluss=11 ON=DISK STAUCTURS : PAGE 37 


EXAMPLE: 3 byte record pointer 


ID |} N RECCRD ID. 

if H 

a a Se ee ! , 

: LSB | Nel BUCKET POINTER 
I } 

bere es eee ! 

MSB | N+¥2 


7.0.1.9 Packed Decimal Strinzs 


Packed decimal strjngs are from 1 to 16 bytes in 
lenztn. The format is as follows: 


7 4 3 0 

di d2 1 A 

i 63 i @4 | A+1 

: @i jj sign | A+N<1 
where: 


d = digit in the range of 0O thru 93 (bdinary 
value) 


Sign is plus if value is 10, 12, 14, or 15 

Sign is minus if value is 11 or 13 

N is length of eeesnes: tn bytes 

i = (N-1)#2+1 and is an nae number in the range 
of 1 thru 31 

di is most significant digit (may be a leading 


zero) 


di is least significant dizit 


sd RMS FILE ATTIRIBUTES 
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RMS stores attribute information about one Tite tm tne 
file's user attribute area (H.UFAT - see Section 3.4.1.9} 
at uses the first ten (10) words; the rest are reserved odby 
RMS. Tne following items are contained in the attribute 
area; tney are identified by symbolic offsets into an AMS 
internal structure, The relative offsst ints the Settribvie 
area may be calculated By sudtracting FSFORG from the giver 
offset name/value. The offset definitions may be defined in 
assemoly language programs by calling and invoking tha macro 
IfraQrs RMSSL. Flag values and bits may ode defined dy 
calling and invoking the FABSBT DFINSL macro. These macros 


can be found in the RMSMAC.MLB macro library on all PDP-11 
Systems supporting RMS. 


ray ee FSFORG 1 Byte Record Format and File Organization 


This byte identifies the file's: organization and 
which type of record format it contains. The 
record format is contained in bits 0 = 3, and the 
file's organization is contained in bits 4 - 7. 
The symbolic values are defined such that they aay 
be OR'ED to yield the contents of the FSFORG 
field. 


Record Formats: 


. FBSUDF Undefined record format (Block I/0 oaly 
file) 


FESEFIX Fixed length records 
FESVAR Variable Length records 


FBSVFC Variable with Fixed Control (VFC) records 

| (the FCS R.SEQ is a special case form of 
the record format i.e., the fixed control 
area is two bdytes long and contains the 
records sequence number) 


FBSSTM ASCII stream records. RMS-11 used only 
as a means for RSTS/E ASCII data 
interchange. Records are delimited by 
vertical form effecter characters (LF, 
VT, FF and CR/LF pairs). 


File Organizations: 


FBSSEQ Sequential File organization (FBSSEQ = 9 
to maintain compatibility with FCS) 


FESREL Relative File organization 


eee ee eee sme + Sh Ski) Am etek oe 


FBSIDA Index File organization 
FBSHSH BEasned File organization (not implemented) 
qe Vege Potal. ‘) Byte Record Astro ounces 


This byte contains record attributes bits that 
control tne handling of récords under various 
contexts. The following flag bits are defined: 


FBSFIN See Section 6.1.2 FD. IN 
FBSCR& See Section 6.1.2 FD.CR 
FBSPRN See Section 6.1.2 FD.PRN and 6.2.2. 


FBSBLK Record do not eress blo2k ee al 
whe Sequential file organization i 
See Section 6.1.2 FD.BLK for gore qd 


Cet FSRSIZ 2 Bytes Record Size 


In file containing fixed length format records 
. this word contains the size of the records in 
bytes. In Sequential files containing variable or 
variable with fixed control formatted records this 
Field contains the size in bytes of the longest 
record in the file. This field is undefined for 
Relative and Indexed files containing variable or 
Variabdle with fixed control format records. 


7.1.4 FSHVBN 4 Bytes Highest VBN Allocated 


RMS updates this field wnenever the file is opened 
for write access. For details on this field see 
Section 6.1.4 F.RIBK. | 


Lees FSHEOF 4 Bytes End of File Block 


This 32 bit number is the VBN in which the end of 
Pie is located ror the Sequential file 
Organization. Both FSEVBN and FSHEOrF are stored 
With the high order nalf in the first two bytes, 
followed by the low order half. "The low order 
half is symbolically referenced by FSLYBN and 


mn rremene quneem met 2 ee Os a eens 
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FSLEOF respectively. These are the only two 
places tnat RMS stores block numbers in this 
manner (see Section 7.0.1), and is done so to 


Maintain compatioility with FCS. The Relative and 
index file does not use this field and its value 
is usually ~ (but not guaranteed) either the. 
contents of FSHVBN or the contents of FSHVSN plus 
One. 


FSFFBY 2 Bytes: First Free Byte 


This field is used for the Sequential file 
organization” as 2 count of the number of bytes in 
use in the virtual block containing the end of 


file. The Relative and Indexed file organization 
do not use this field and its value will be either 
0 or 512. For more details on this field see 


Section 6.1.6 F.FFBY. 


FSBKSZ 1 Byte Bucket Size 


This field contains the bucket size or maximum 
bucket size for the Relative and Indexed file 


organization respectively. The bucket sizé is 
represented as the number of virtual blocks it 
contains. Legal values are from 141 = 32. For 


compatibility with FCS a value of 0 is interpreted 
as 1. | 


FSHDSZ 1 Byte Fixed Header Size 


This field contains the number of bytes (1 = 255) 
in the fixed control area when the file contains 
Variable with Fixed Control format records. A 


value of 6) is interpreted as 2. so that 


compatibility with FCS'S Sequenced Variable length 
record format file (R.SEQ) is maintained. 


FSMRS 2 Bytes Maximum Record Size 


This field contains a user specified maxinun 
record size limit in bytes, to be enforced on 
output operations. Files containing Fixed lengtn 
format records have FSMRS set equal to FSRSIZ. 
For all other record formats FsMkS is sec to the 


user specified value given when the file was 
Created. A value of Q is interpreted as no 
maximum record size limit specified. 


FSDEQ 2 Bytes default Extend Quantity 


This field contains a user specified default fiie 
extend quantity to oe used whenever RHS needs to 
extend the file. A value of 0 is interpreted 2s 


use the volumes default extend. 


Plues—11 ON-=-DISK STRUCTURE - PAGE +2 


f7.1.aA RMS File Attributed Layout 


! Record Attr. | File Org./ree fat ! FSFORG 
| Record Size (bytes) sstS~S | FERSIZ 
| Righest VBN | FSHVED 
a Allocated a 
a ind Of file | FSHEO# 
_ VBN 4 
fibaedae sae sooneeeeteceeeneateeaeeocea= ! 
! First Free Byte ! FSFFBY 
FsHDSZ «| Fixed Ctr. Size | Bucket Size | FSBKSZ 
"Nakiaua aesord Size Liaie awa 
| Default Extend Quantity ™” | egpga 


To calculate the offset into the User Attributes area in the 
file hneader subtract FSFORG from all symbdolic offsets. 


dense Prologue Blocks 


The RMS Relative and Indexed file organizations use the 


first several virtual blocks of the file to contain 
additional file description data. This area of the file is 
called the file prologue.-: In the Relative file 
organization, the prologue is exactly one bleeck long; in 


tne Indexed organization its length varies. The symbolic 
effset names, and flag values and bits used in the file 


prologue Blocks and record formats may 6¢ obdtained by 
calling and invoking the following macros from the 
RMSMAC.MLB macro library on all PDP-11 systems supporting 
RMS. 3 


ARDOFS$ RMSSL 
BKTOF$ * RMSSL 
KDXOFS3 RMS$L 
KDX$BT DF INSL 
AABSBT DFINSL 
BSKTSBT DFINSL 


The last word of every prologue olock contains th 
standard Files-11 eheck sum (see Section 3.4.4.1). 
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1wes Prologue Block 1 (VEN 1) 


Prologue Block: 7} Genteains -common; data for botn ne 


ndexed and Relative files, and file organization dependent 
ata. Tne major Indexed file dependent data is the primary 
ey definition (the KSKXXX symbols). The maior Relative 
ile cependent data are the maximum record number, tne 
adaress of the first data bucket, and the "real" End of File 
Block (last initialized, zeroed, VBN). The primary sy 


Cefinition offsets (X3XKXKX) are used for all key definitions 
within the prologue of the index file and are relative to 
the start of each key descriptor. 


The key definitions supply all tne information needed 
Oy RMS to retrive, insert, update, and delete records for 
tne Indexed file organization. Tne basic data which are 
contained in a key definition are as follows: 


-. Where the associated key field is positioned in the 
record, and how long it is. | 


- the VEN address of the associated Root bucket. 


. Various key field options 


Tne Key definitions are linked into a ch@in by the ¥8N 
address and byte offset within the prologue block for the 
next Key definition. Tne Indexed file organization can be 
viewed as a multi-partitioned file. The first partition is 
the prologue, the second partition is the index associated 
witag the primary key definition, and the third partition is 
the user data associated with the primary index. Every 
indexed organized file contains these three partitions. In 
addition wnen alternate keys are defined then two additional 
partitions per alternate Key are created. The first 
partition is the index associated with the alternate key 
definition, and the second partition is the RMS data 
associated with the index. The RMS data contain pointers 
into the user data partition for the records meeting the 
various key values. The index is structured as an n'ary 
tree where the nodes of the index are buckets. The index 
Structure is the same for all key definitions. 


Poe et <SNLVB 4 Bytes VBN for Next Key Descriptor 


This field contains the virtual block address in 
which the next key descriptor may be found. This 
Tield is only looked at. when the XSBNYT field 
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contains a 0. When X$NLVB and KSNEYT = 0 the last 
key descriptor has been found. The least 
Significant i6 obits of the VBN are stored in 
KENLVB and the most significant 15 bits are stored 
in KSNLVB+2 (XsNHVB). | 


Teeu lee KSNBYT 2 Bytes Byte Offset for Next Key Descriptor 


This word field contains the byte offset relative 
to the beginning of the VBN contained in KSNLVB 
for the next key descriptor in the chain of key 
descriptors. The first key descriptor contained 
in a VBN starts at byte offset 0, and the ecnain 
Will thread through the current VBN before zoing 
to the next VBN. This means that the VBN will 
only change when KSNBYT contains a QO. 


wee lies KSIAN 1 Byte Index Area Number 


This byte contains the number of the Allocation 
Area to use for the index Buckets associated with 
this key starting at level 2 going up to and 
including the Roots bucket. | | 


eee tee KSLAN 1 Byte Lowest Level Index Area Number 


. This byte contains the number of the Allocation 
Area to use for Level 1 of the index buckets 
associated with this key (a value of 0 means use 
the contents of K$IAN). | 


1245 KSDAN 1 Byte Data Level Area Number 


This field contains the number of the Allocation 
Area to use for the data level (level 0) of the 
index buckets associated with this key descriptor. 


Lace wes KSLVL 1 Byte Level of Root 


This field contains the level number of the Root. 
Bucket associated with this key descriptor. This 
field is not supported by RMS-11 release one. 


NN) 


Nh 
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K$I5K4S 1 Byte Index Bucket Size. 


This field contains the oueketsb size 
ald. index Level. Cilevel. } fthrousen 
3 


puckets (1 + 32) for this key descripto 


n YBN'S ror 
e root level) 
ye 


€SsD8XS 1 Byte Data Bucket Size 
This field contains the bucket size in VBN'S for 


all data level. (level 0) buekets (1 - 32) for this 
Key descriptor. 


P$D38KS 1 Byte Data Bucket Size 


Tais is a symbolic redefinition of K$DBKS for use 
Dy the Relative file organization. 


X$LVBN 4 Bytes Address of Root Bucket 
This field contains the bucket address of the Root 
Ducket for the index. associated with this key 


descriptor. The 32 bit VBN is stored in the 
Banner described in Section 7.2.1.1. 


KSFLGS 1 Byte Key Descriptor Flags 


This field contains a bit vector for the various 
key options supported by RMS as follows: 


XBSDUP Duplicate key values allowed 


XBSCHG - Key value may change on  3UPDATE 
operation 

XBSNUL Null key character enabled (KSNULL) 

XBSINI index must be initialized 


When the XBSINI bit is set the K$LVBN field 
contains the following: 


KSLVBN = C(X$SDAN) 
KSLVBN+1 = C(X3IAN) 
KSLVBN+2 = C(KSLAN) 


KSLVBN+3 QO not used 
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This information is used once only when the index 


for this key definition is created. Since the 
area number information is not normally stored in 
tne in memory data base for an open indexed file 
the required area numbers to create the index are 
Stored in the root bucket field for this once only 

ne 


Operation. The area numbers are not needed in ¢} 


. 93 


in memory data base since on future bucket: 
allocaticn tne area number stored in m2 oucket 
wnich is "splitting" is used as the area number to 


allocate the new bucket from (see section 
L253 lelee?. 7 


PSFLGS 1 Byte Prologue Flags 


This field is a symbolic redefinition of the 
KSFLGS field for use by the Relative file 
Organization. Bits defined for this field are: 


PRSNEX Error encounted extending Relative file 
no further extending is possible. 


KSDTP 1 Byte Data Type for Key 


This field contains the data type of the key field 
within the user data records. The only legal 
Value currently for RMS-11 is ABSS 1G ys. The 
following data types are defined. 


XBSSTG String data type (unsigned 8-bit bytes) 


XBSIN2 Signed 15 bit integer (2-bytes) 
XBSBN2 Unsigned 16 bit binary (2 bytes) 


 XBSING Signed 31 bit integer (4-bytes) 


XBSBN4 Unsigned 32 bit binary (4-bytes) 
XBSPAC Packed decimal (1-16 bytes) 


KSNSEG 1 Byte Number of Segments in Key 


This field contains the number of segments (1 = 8) 


that make up the definition of the logical key 


field. The XBSIN2, XBSBN2, XBSIN4, XBSBN4, and 
ABSPAC key field data types may only contain one 
(1) segment. 


K$NULL 1 Byte "NULL" Character 


Lois field contains 2 User soecified eharacter: 
If the key field within the data record associated 
WECQ Chis: Key -descriotor conteins oniy “nuit 
Gner2ecters the record -wiil. not be inserted into 
the associated Index. Tne "null" value for the 
XBSIN2, XBSBN2, xXBSIN4Y, KBSBNY, and XBSPAC key 
field data types is defined as zero (0). This 
field is enabled by the XBSNUL bit in the KSFLGS 
and is only valid for alternate keys. 


K$KYSZ 1 Byte Total Key Size 
This field contains the sum of all tne key segment 


sizes to yield the total size of the key field in 
bytes (1 = 255). 


KSXEY 1 Byte Key of Reference 


This field contains tne key of reference number (0 
- 254) for this key descriptor. Primary key = 0; 
alternate keys = 1 = 254. | 


KSMINL 2 Bytes Minimum Record Length 


This field contains the minimum length record in 
bytes to contain tne complete key field. 


KSIFIL 2 Bytes Index Fill Quantity 


This field contains the number of bytes to use for 
index level buckets (levels 1 - n) before a bucket 
split is considered when the user requests RMS. 609 
follow fill quantities. 


K$DFIL 2 Bytes Data Fill Quantity 


This field contains the number of bytes to use for 
user level buckets (level Q) before a&@ bucket split 
is considered when the user requests RMS to follow 
Fill quantities. 


7334.36 
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KSPO0S 16 Bytes Key Segment Offset Positions 


This is a set of eight (8) 2 obyte field 
(X$POSO-K$P0S7) which contain the relative offse 
(O = n) into the data record for each Key segment. 


K$SIZ 3 Bytes Key Segment Size 


This is a set of 8 1 byte fields 
which contain. the size in 
Segment. 


(KSSITZ0-X%3S127) 
dytes for the key 


KSANM 32 Bytes Key Name 


This is a 32 byte string supplied by the user when 
the key was defined. If not supplied will contain 
NULLS. | 


KS$LDVB 4 Bytes First Data Bucket 


This field contains the bucket address of the 
first bucket at the data level (level 0) 
associated with this key descriptor. Inte fLlele¢ 
is mot supported by RMS-11 release 1 and contains 
a zero. 


14 Spare Bytes 


PSAVBN 1 Byte VBN of First Area-Descriptor 


This field contains the VBN (2 - 255) of the first 
Allocation Area descriptor block. Allocation Area 
descriptor blocks are virtually contiguous and are 
directly accessed by area number. See Section 
tgewsx 


PSAMAX 1 Byte Maximum Number of Areas ~ 
Thais field contains the maximum number of defined 


Allocation Area descriptors ( 1 - 255) for this 
file. Eight (3) Allocation Area descriptor can 


+ eee ween eee Nee rete ee - Te er eee me ae nat ee eee me ~~ wen mew: : eee ee + ee een ee 
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fit ina virtual block since each area descriptor 
is 64 bytes long. The file address of any Area 
agescriptor may be calculated as follows: 


Let: @= area numoer (0 = 2534) 
Vv = VEN address for 2 
OS Cf rset. 2nt6 Vv for 4 

Then: vs a/8 (truncated) + e(PSAVEN) 
o = (a mod 8)*64 


PSDVBN 4 Bytes Address of First Data Bucket 


This field ecoantains the 32 bit VBN of tne first 
data bucket in @ Relative file. 


PSLMRN 4 Bytes Maximum Record Number 


This field contains the .user specified maximua 
record number which will be allowed on 8s32UT 
Operations to the Relative file organization. if 
the user specifies 0 then this field will contain 
the maximum record number possible (2%#31-1). 


PSLEOF 4 Bytes EOF VBN 
This field contains the last initialized (i.e., 


zeroed) VBN (i.e., the EOF VBN) for the Relative 
file organzation. | 


PSVERN 2 Bytes Prologue Version Number 


This field contains a prologue version nubmer. 
The only legal value at this time is one (1). 


Reserved for Future Use 292 Bytes 


Prologue Checksum 2 Bytes (see 7.2) 
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VBN For Next Key 


Descriptor 


Offset To Next Key Desep. 
“Level 1 Aves» | Index Area? 
“Root Level «| ‘Data Area # 
‘Data Bets | ~SsIndex Bkts 

Size ! Size 
Rat Bucket SSSS™S~S 
: Pointer 
"Data Type =| FldgsS™” 
"NULL" Character | # of key segments 
Key Of Ref. | Total Key Size 
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Minimum Record Length: 


Key Field Segment 
Offset Positions 


(KSPOSO0-K$P0S7) 


Key Field Segment Sizes 
(K$SIZ0-K$SIZ7) 


Key Name Stringz 
(32 Bytes) 


rirst Data Bucket 


—enw Tew sea oe eR uw aoe 


om em oem eee 


KSNLVB 


KSNBYT 
KSIAN 


KSDAN 


KSIBKS 


KSLVBN 


KSFLGS ~ 


PSFLGS 


_KSNSEG 


KS$KYSZ 
K$MINL 
KSIFIL 


KSDFIL 


KSPOS 


K$SIZ 


KSKNM 


KSLDVB 
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Pointer 
1 | 
ee eae eae a eee ere ee me Se ee eee eee 
/ Spare (14 Bytes) / 
ee ee eae eae @oeweeenew @ @ @® @ w = ea op a 
PsaAMAX | Max Area # ; VBN Of 1st Area 'PSAVBN 
{ ! 
SS SS eS Se eS ee eee 
} Start VBN of ist Data Bucket | PSDVBN 
| ! 
;2o ae 
(rpélative file -only) 
} H 
(See ee ee SS eS SSS a a SS eS SSS a ee ee 
Maximum Record | PSLMRN 
i } 
jo= se} 
Number ! 
i} | 
jpewwrnrwoesewnwwoaeanan waa wee @ am ma «2; a a ap b> > Dp =» ae ah 2s aD GD aD 1 
Relative File SOF VBN | PSLEOF 
1 j 
(Last Initialized VEN - Zeroed) 
i { 
4 ae ae ee See ae ae eee a es ee Soe og 
Prolozue Version Number | PS$VERN 


Block CheckSum 
Byte Offset 510 
] « 
1 


7.2.2 Alternate Key Prologue Blocks 


Alternate key prologue blocks are chained tegether 
through the X€$NLVB field of the key descriptors (see Section 
7.2.1.1). Five alternate key descriptors can fit in a VBN. 


1.2.3 Area Descriptor Prologue Blocks 


The Indexed file organization requires a method of 
allocating the virtual blocks of the file to the various 
usages within the file (e.g., Index buckets and Data 
buckets). The structure which allows this virtual block 
allocation management is tne Area Descriptor. The Indexed 
File supports multiple allocation areas to achieve tne 
following user file design capabilities: 


1. Different oucket sizes between the index buckets 
and associated data buckets. 


2% Different index and data bucket sizes on 2 per key 


r 
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Dasis. 
5. Allocation placement control for the various 


elements of the file. 


Bignt area descriptor ean be contained in a2 virtual 
block, and all the area descriptor prologue blocks 2rsa 
virtually contiguous (see Sections 7.2.1.26 and 7.2.1.27 for 
mors details). : 


(22e361 Spare 1 Byte 
Tsew ge ASFLG 1 byte Flags (not used) 


Ts2535%3 ASAID 1 Byte Area Number (0 - 254) 
This byte contains the Area's number and is used 
as a redundancy check since all area descriptors 


= are located at a fixed relative position -+to the 
start of the Area Descriptor prologue blocks. 


2 2s344 ASBKZ 1 Byte Bucket Size for Area 
This field contains the areas's bucket size in 


blocks (1 - 32) which is the granularity of 
allocation. 


7.2.3.4  ASVOL 2 Byte Relative Volume Number 
This field contains the relative volume number for 


the last file extend for this area when placement 
control was requested. 


(Bu Se3 ASALN 1 Byte Extend Allocation Alignment 


This field contains the allocation alignment used 
for the last file extend for this area. 


Legal values for this field are: 


QO placement control not requested 
ABSCYL cylinder alignment (not implemented) 
XBSLBEN logical olock alignment 

ABSVBN  $virtual block alignment 

ABSHrI allocate close to related file 


by FID (not implemented) 


As40QP 1 Byte Alignment Options 


This field contains option bits to qualify the 
ASALN field. Legal values are as follows: 


XBSHRD Alignment is absolute and fail if 
available (note: illezal for XBSVBN or 
XBSRFI alignment). 


XBSCTG Allocation is to be contiguous. 


ASAVL 4 Bytes Available (Returned) Buckets 


This field contains the 32 bit VEN of the first 
available bucket in a chain (linked through the 


first 4 bytes of the bucket) of buckets. This 
Chain of buckets would be the result of returning 
Buckets back to the area. - The returning of 


Duckets is not currently supported by RMS so that 


€he only legal value for this field is zero (9). 


ASCVB 4 Bytes Start VBN for Current Extent 


This field contains the 32 bit start VBN for the 


current extent. The current extent is the extent 
from which buckets will be allocated. 


ASCNB 4 Bytes Number of blocks in Current Extent 


This field contains the number of blocks that were 
allocated to this current extent. The combination 
of ASCVB and AS$CNB describes in virtual block 
Cerms the result of the file extend operation for 
the current extent. 


ASNUS 4 Bytes Number of blocks used 


oe 
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This field contains the number of ploecks that. have 
been allocated from the current extent. 


ASNVS 4 sSytes Next VBN to Use 


This field contains the 32 bit VBN to use for tne 
start YBN of The next bpucket allocated from the 
current extent. 


ASNXT 4 Bytes Start VBN for Next Extent 


This field contains the 32 bit start VBN for the 
next extent. When the current extent is used up 
the next extent is made tne current extent and the 
next extent description is zeroed. The area can 
Only be extended when the next extent description 
is zero. 


ASXBY 4 Bytes Number of blocks in Next Extent 


This field contains’ the number of blocks that weré 
allocated to- this next extent. Thie- combination 


of ASNXT and ASXBY describes in virtual block 


terms the result of the file extend operation for 
the next extent. 


A$DEQ 2 Bytes Default Extend Quantity 

This field contains the user specified default 
file extend quantity to be used whenever the area 
is to be extended by RMS. A value of 0 means use 


the file's DEQ. However, in no case will less 
than one bucket size for this area be requested. 


Reserved 2 Bytes 


ASLOC 4 Bytes Start LBN on Volume 


ToLs field contains the start logical block number 
for the last extent performed for this area. 


oo ane ae ee, vert mememer 9 note = PEE om | wemereee ere - ee a we me eee 
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7.2.3.17 A§$RFI O Bytes Related File ID 


This field contain the FID of a related file ror 
the XBSRFI allocation alignment CASALN) not 
implemented) 


7.2.5.16 Spares 12 Bytes 


7.2.3.19 ASCRC 2- Bytes Checksum 


This field is a dummy field to pad out the area 
decriptor to 64 £=bytes. This also allows the 
Standard Files-11 checksum to 6¢e stored in the 
last word of the Area Descriptor Prologue bdlock. 
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Area Descriptor Layout 


1 Relative Yolume Number 


j ! 
t t 
List 
} 


{ 
: i 
‘Start: VEN For 
Current Extent 


1 
} 
Number Of VBN's In 
Current Extent 4 
! 
' 


Number Of VBN's Used 
In Current Extent 

t 

§ 


Next VBN To Use For 
Current Extent 


if 
: j 
Start VBN For - : | 
Next Extent : 
i t 
i 2 2 ee a> @@ o@ ab oD ah GD GD GP GD a® Cf oD OD oD G&D @ «of oD oD 2 oF oD EB GD GD OS Ge 4 of ae o> «4 =o? @ a t 
| Number Of VBN's In 
Next Extend : | 
t ! 

1 


Start LBN For Last 
extend For This Area 
File ID For 
Related File For 
File Extends 


eeu emew ave 
owon ewes as =e 


quae we ee a= 


spares 


ower en aw amew coe ee eee 


ee woe 


ASAVL 
ASCVB 
ASCNB 
ASNUS 
ASNVB. 
ASNXT 


ASXBY 


(‘ooo Sequential File froraa . 

Tne RMS Sequential file is compatible with the FCS 
fixed and Variable lenzsth record files. Please refer to 
Section 6.2 throush O4223. The RMS variable with Fix 
COntrol. recerd format is 4 eeneralizaticonr oi tne Sequenced 
Varialbe Lengtn Records of FCS (Section 5.2.3) in that the 
fixed control area (always 2 bytes for FCS) can de varied 
between 1 to 255 bytes. 

7.4 Relative File Format 


The Relative file currently uses. virtual block one (1) 
for its prolozue, and starts its data buckets at virtual 
Olock 2. Reeords are stored in fixed length eells within 
unformated buckets (no overhead bytes in bucket) starting at 
oyte 0 and packed end to end (i.e., byte alignéd). The 
virtual blocks within the relative file must be initialized 
(zeroed) when tney are allocated to tne file to support 
deleted record control. 


7.4.1 Relative File Record Formats 


Records aré stored in fixed length cells. | The first 
byte of eacn cell is a record control byte used to provide 
deleted record control. The following bits are defined: 


DCSDEL record has been deleted 
DCSREC record exists 


A value of 0 indicates ths cell has never contained 2 
record. | 


The relative file supports variadle and variable with 
fixed control length record up to the required user 
specified Maximum Record Size (MRS)... In these eases the 
record control byte is followed with a two byte Dinary count 
of the bytes in the record (the count does not include 
itself). If the cell size does not evenly divide the bucket 
size then the remaining space in the bucket is dead space 
and the next record in the file will be stored in the first 
eéll of the- next bucket. In other words records never span 
Ducket boundaries. 
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cell size = MRS+3 


3 


7.4.1.C Variable With Fixed Control Records 


' otrl ! size |} fixed | data (size-fixed ctrl bytes) | 


cell size = MRS+FIXED CTRL SIZE+3 


7.5 Indexed File Format — 


The Indexed File uses virtual blocks 1, 2 and if 
necessary uo to and including 84 as a maximum for its 
prologue. The current implementation on the PDP-11 will 
result in a prologue of the following forms: 


Single Key 


PRIMARY KEY 
VBN 1 Description 
} { 
' | 
b j 


{ an ap aD 42 22 of a@D o® = oe GP =D wf EQeenwDmen een ewe eee @ewe @& @ i 


| PS$AMAX |  PSAVBN a 


VBN 2 
Area Descriptors 


—_— ~- ~~ os; 
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ow) 
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DSS 
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tw 
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cr 
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Index and Data 
Buckets 
{ j 
{ | 


Multiple Key 


Primary «éy 
Descriptor 


VEN 1 


PSAMAX {| PSAVBN 


} 
| 
SS aan ee a =a» at =D ap ae mma © = = - = 
! 
1 
\ 
! 


° ODE ne Owe @© 2 ew ee we ee we @ ww hw @ @ © @ @ = 


VBN 2 | a eee 


wone Ga ewe mw ee OP ee ee ee ee ow 


! 
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Descriptors 

. i 

} 
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$ 
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index and data bucket space starts at: 


((PSAMAK/&( TRUNCATED) )+PSAVBN) 


Records are stored in formatted buckets (buckets have 
overhead oytes) and are packed end to end (i.e., 
aligned). The Bucket format and the various record formats 
aré given in the following sections. 


7.5.0. Index Structure 


Tne Index is structured as 2 dalanced tree. The nodes 
in tne tree are buckets, and tne nodes are serially 
séarcned. gi contains index records as 


ne Index node 
specified. 2m Seer les J .se2< i 
The bucket size is constant for index nedes, but may | 
different than the Data buckets. Tne Data SucKket r 
toe same size. 


Each level of tne index is horizontaly linked via the 
Next bucket pointers. The. nerizontal Linking is::-eLtreuler 
with the last bucket (noted oy BCSLBK) pointing back to the 
first bucket. . Tne Data buckets for an Index may be viewed 
as the data level (set) of the index and are linked in tha 
same manner as buckets in any otner level of the Index. 


Figure 7-2 shows the structure cf the Incex. 


Tne key value associated with index records (se 

S¢eticea («<5<2.i): ds: Qhe Rienest ‘or nignest. cossi ole “ey 
valus in the bucket peinted to by the bucket pointer in tk 
record. : 


Tne basic search rule for_an index search is to follow 
the first path for which the search key is equal to or less 
than the key value stored in the index record. a 


~ 


7.5.0.1 Primary Key Index Structure 


The primary key index for 42 file is structured 42s 
stated in Section 7.5.0 above where the data level is 
composed of buckets which contain the User's data records. 
Tne data buckets may also contain RRV records. See Section 
Teoc0es end. {faseeus for Cetaits on ARV records: 


7.5.0.2 Alternate Key Index Structure 


An alternate key index for a file is structured as 
stated in Section 7.5.0 above where the data level is 
composed of ouckets which contain pointer array records as 
specified in Section 7.5.2.4. Therefore the indices within 
the Indexed File Organization have the same structure, where 
only the interpretation of the records within the data level 
of an index is different. 


7.5.03 Record Reference Vector (RRV) 


OV 
tw 
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when a record is inserted in an Indexed file the record 
is assigned 32 reference vector address and tnis address is 
Stored in the data record in the record pointer field (see 
SSeelionm. TsS2.242) x This address is the initial address of 
tae record itself. Whenever the record is moved tne 
record's reference vector record - is updated with its new 
address. Tne record, in turn, points back to lts reference 
vector so that it can be updated if the record is moved 
again. Tne reference vector record is created when the 
record is moved for the first time. Using this tecnnique 
the worst case indirection for a record is kept at one, and 
we ecan always find the record via its reference vector 
address. | | 


Tne record pointers used within the Indexed file 
organization, and the RFA (Record's File Address) returned 
to the user in tne RFA field of tre RAB are always the 
recora's reference vector address. 


The space required for RRV pointers in the data records 
of a file is required to insure RFA addressing and alternate 
Keys. The RRY records are stored at tne and of tne data 
records in the user data buckets. he use of RRV's and 
seconaary indices is graphically shown in Figure 7-3. 


Tne Indexed orzanization uses 2 formatted dOucket as its 
primary unit of seondary storage. A bucket is composed or 
some nuader of virtual blocks in the range of iei2 and has 2 
neader starting at doyte one of tne DucKxect. 


Tae Buexet is composed o é 
ar2a, a Record storaz¢ area anda F 


Each of these ar2zas will be described in tne sections 
tnat follow. 


| ao rae ee header Area 


Tne bucket header area is composed of a RAS 


data 
section, @a dSuceket storage control section, and 32 
Structure link section. The size of the bucket 
header is 14 bytes (S$BHD). 
7.5.1.1.1 BSCHK 1 Byte Check Byte 
: This-is a one byte check:- character. Whenever a 


"oucket is written the value in the check byte is 
changed and copied into the last byte of the 
bucket. Whenever a bucket is read tne eneck byte 
is compared to the copy for equality. BY Ais 
technique hardware failures during transfer ars 
detectable (i.e., the BUS breaks etc.). 


7.5.1.1.2 BSTAA 1 Byte This Allocation Area 


This field contains the allocation area numder 
that this bucket was allocated fron. 


7.5.1.1.3 BSADR 2 Bytes Bucket Address Sample 


tab 


This is a sample of the bucket's start VEN 
address, and is composed of the low order 16 bits 
of that address. This field is written upon 
bucket formatting, and is checked whenever the 
Ducket is read into main memory. 
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BSNBY 2 Bytes Next Available Byte 


ego) 


Tnis field contains the byte address relative 
ree byte in 


tne start of tne Ducket ofr the first f 
the Free Stcrage Area of the bucket. 


BSNiD 1 Byte Next Available ID 


This field contains the ID number to use for tas 


next record placed in the bucket. 


BSLiID 1 Byte Last Available ID 


This field contains the ID number of the last LD. 


in the contiguous range of ID's specified by tne 
contents of BSNID and BSLID. When the contents of 
BSNID are greater than the contents of SS$LID or is 
zero then tnere is no "next" available ID. When 
this condition occurs the bucket is scanned to 
find tne largest contiguous range of unused ID's 
and BSNID and BSLID are updated to describe that 
range. 


BSNBK 4 Bytes Next Bucket Pointer 


This field contains the start VBN of the next 
bucket at this level of the index or data 
partition for the Indexed file organization. This 
pointer always points to a bucket of the same 
size. | 


BSLEV 1 Byte Level Number for Bucket 


This field contains the level number relative to 
the data level for this bucket, in the index. The 
Data level buckets contain a 0, the lowest level 


buckets of the index contain a i, the next level 


buekets going towards the root contain a 2 etc. 
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NCTe : 
"Date bueKxets" refer to the buckets whien 
contain the data records associated with 
the index. For tne primary index these 
are tne user data records, and for the 
alternate index these are system data 
records which contain an array of pointers 


$O user data records. 


7.5.1.1.9 B3BCB 1 Byte Control Bits 


(oreo are 


aos a 


ts) 


evens 


This is a bit encoded byte field and is used in 
tne processing of a2 bucket. The following bits 
are defined for the indexed file organization: 


BCSLBK = last bucket in level 
BCSROT = root bucket of index 


Record Storage Area 


The record storage area starts at the first byte 
after the bucket neader area, and ends at the byte 


address stored in BSNBY minus’ one. The record 
Structures in buckets vary with the use of the 
bucket. Section 7.5.2 specifies the various 


record structures used. 


Free Storage Area 


The free storage area starts at the byte address 
stored in BSNBY and up to the check byte copy in 
the bucket. Any and all free storage statistics 


refer to this contiguous free storage area. 
However it is possible due to "fast" record 
deletions to have "free" space within the record 
storage area of the bucket. The reclaimins of 


this space is done on an as needed basis. 


S$BHD 14 Bytes Size of Header Area 


This symbol represents the size of the bucket 
header area. 
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{eas re ee Bucket Format Layout 

BSTAA | Tnis Area | Check Byte | BSCHK 
I: ! 
(222 SS SS SS aS eS aS SS Se SSS eS 
bucket Address Sample | BS$ADR 
i ! 
a ee ee ee ee ee ee ee ae ee a | 
Next Available Byte | BSNBY 
{ j 
eee SS RSS eS See Kea SSS 

B$LID i Last ID 1 Next id | B3NID 
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she pointer size as follows: 


2 byte bucket pointer 
3 byte bucket pointer 
4obpyte bucket pointer 
undefined 
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7.5.2.2 General Data Bucket Record 


| DRCB ; PS 1 Byte 

! { 

HY ea QSQeoeeeemeeee @& a { ; 

ID i 1 Byte 

) } 

j eo @eeceeaewweeeaaqa«a - 1 

| Record | N Bytes Optional 

| Pointer 

| { 

{ e@mempe~)+1» =p = 2 «2 282 2 Ge @ a t 

Size ' No Size If Fixed Length Data 
=m 4D) 4B) ep ew ase oe eb ap a» @ ae aD t *, 

! ar 

Data i .M Bytes 

{ { 

( ( 


M = Size Or Fixed Lenzth If No Size 


DRCB contains Data Record Control Bits 


The following bits are defined in the DRCB byte: 


DCSDEL 


DCSRRV 


DCSNPS - 


6 


DCSKDL 


DCSNCP 


PS is tne 


follows: 


wn — Oo 


Record deleted, or pointer to deleted 
record. | 


Record reference vector record. . 


No pointer size field present (qualifies 
PS} _ 


Pointer to record for this key no longer 
applies $UPDATE changed the key, but 
record exists; note ID will be zeroed 
on all systems starting with Release 1 


on RSX-11M V3. 


Do not compress this deleted record: 


pointer size for the Record pointer as 


3 byte record pointer 
4 byte record pointer 
5 byte record pointer 
undefined 


fie oe i SONU on Oasis oa 
7.5.2.3 RRV Records 

Record Reference Vector (ERY) records ars 
SOine co toe record associated with the reve 
They functica 25 -“Torwarding. eddréesses” for 


records wnen tney are moved. 


The RRV record for 


,tnhe 


following DRCS oits are set: 


is 


DRCB ; PS 

i a 
Record 

Pointer 


Woere the DCSRRV 


BLETED. RAV 


first two bytes 


DOSRRV 
DCSNPS 
DCSDEL 


as; follows: 


sit is set in tne DRCB Pi 
RECORDS , 
a deleted record can be 
of the RRV record. in 


2S 6m4) 1 
this case 


as 
tne 
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7.5.2.4. Secondary (or alternate) Index Data 
for wnicn duplicate keys are allowed 


Data 
on 
Record 


Tne 
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Gata records 2ssociated with an alternate 
pointer arrays to the users data records. 
record is as 


follows: 
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Record (SIDR) 


K at 
- 


a "Ss 
ww ~~ 
of the 


ind 
The Format 


Byte 
Byte 


Bytes (DCSNPS=0) 


Size Bytes 
| Key Value Bytes 
SIDR Record Byte Pointer 
Pointer #1 Array 
SIDR Record Bytes record 
Pointer #2 
; 
4 e I 
; 
} § 
' e t 
SIDR Record Bytes 


' $ 
| } 
Pointer #X 


Fields within the pointer array record 


PS 


DRCB 


This field contains 
duplicate count field 


3 bytes 

4 bytes **THIS IS 
ED*#*# 

5 bytes 

undefined 


U 


nounnuea 


to ™ 


Bits used for pointer 
NCSNPS Lt: -Lnis Dae 
is no 
TAis is 


Ccontinuations 


the size of zne 
as follows ; 


THE ONLY VALUE 


array records 


is set tnen 


duplicate count field. 
used ror 


ali arra 
records:, Sine 


the count applies to the toral 


array. 


7.5.2.5 Secendary (alternate) Index Data Record - hie) 
Duplicates 

Tas data records asscciated witn an alternate index for 
wnhiecn duplicate key values are not allowed is snown in 
SytULOm «x oeewt: OxXCent thet tans -<duslicate: count. i2eh¢e. 6 
omitted (DCS8NPS=1) and there is only one SIDR Record 
Pointer. wnen a record is deleted tne No Buolicetes SiOz 
record is compressed out of tne secondary index's data 
oOucxetc at tne time of the delete. 


7.5.2.6 SIDR Record Pointers 


The format of the record pointers used in Secondary 
Index Data Records is @s follows: 


Overhead | DRCB } PS | 1 Byte 
Record | Record | N Bytes 
Pointer | Pointer 

3-5 bytes | : 


DRCB bits used for SIDR record pointers 


DCSKDL , Pointer has been, deleted due to key 
change on a SUPDATE operation. In this 
case the ID porticn of the record 


pointer will be zero. 


DCSDEL Record associated with this pointer has 
been deleted. 
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Figure 7-3 
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